home *** CD-ROM | disk | FTP | other *** search
-
- Network Working Group J. Postel
- Request for Comments: 825 ISI
- November 1982
-
-
-
- Request for Comments on Requests for Comments
-
-
-
-
- This RFC is intended to clarify the status of RFCs and to provide some
- guidance for the authors of RFCs in the future. It is in a sense a
- specification for RFCs.
-
- There are several reasons for publishing a memo as an RFC, for example,
- to make available some information for interested people, or to begin or
- continue a discussion of an interesting idea, or to specify a protocol.
-
- Each RFC is to include on its title page or in the first or second
- paragraph a statement describing the intention of the RFC.
-
- The following sample paragraphs may be used to satisfy this
- requirement:
-
- Specification
-
- This RFC specifies a standard for the ARPA Internet community.
- Hosts on the ARPA Internet are expected to adopt and implement
- this standard.
-
- Discussion
-
- The purpose of this RFC is to focus discussion on particular
- problems in the ARPA Internet and possible methods of solution.
- No proposed solutions this document are intended as standards
- at this time. Rather, it is hoped that a general consensus
- will emerge as to the appropriate solution to such problems,
- leading eventually to the adoption of standards.
-
- Information
-
- This RFC is presented to members of the ARPA Internet community
- in order to solicit their reactions to the proposals contained
- in it. While perhaps the issues discussed are not directly
- relevant to the research problems of the ARPA Internet, they
- may be particularly interesting to some researchers and
- implementers.
-
-
-
-
-
-
- Postel [Page 1]
-
-
- RFC 825 November 1982
- RFC on RFCs
-
-
- Status
-
- This RFC is issued in response to the need for current
- information about the status and progress of various projects
- in the ARPA Internet community. The information contained in
- this document is accurate as of the date of publication, but is
- subject to change. Subsequent RFCs may reflect such changes.
-
- Report
-
- This RFC is issued to report on the results of a meeting. It
- may document significant decisions made that impact the
- implementation of network protocols, or limit or expand the use
- of optional features of protocols. Other meeting results may
- be indicated including (but not limited to) policy issues,
- technical topics discussed and problems needing further work.
-
- Of course these paragraphs need not be followed word for word, but
- the general intent of the RFC must be made clear.
-
- RFCs are distributed online by being stored as public access files, and
- a short messages is sent to the distribution list indicating the
- availability of the memo.
-
- The online files are copied by the interested people and printed or
- displayed at their site on their equipment. This means that the format
- of the online files must meet the constraints of a wide variety of
- printing and display equipment.
-
- To meet these constraints the following rules are established for the
- format of RFCs:
-
- The character codes are ASCII.
-
- Each page must be limited to 58 lines followed by a form feed on a
- line by itself.
-
- Each line must be limited to 72 characters followed by carriage
- return and line feed.
-
- No overstriking (or underlining) is allowed.
-
- These "height" and "width" constraints include any headers, footers,
- page numbers, or left side indenting.
-
- Requests to be added to or deleted from this distribution list should be
- sent to NIC@SRI-NIC. Submissions for RFCs should be sent to
- POSTEL@USC-ISIF.
-
-
-
- Postel [Page 2]
-
-